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Abstract: We introduce an approach to risk modeling that we call ‘functional modeling’, which we 
have developed to estimate the capabilities of a lunar base. The functional model tracks the 
availability of functions provided by systems, in addition to the operational state of those systems’ 
constituent strings. By tracking functions, we are able to identify cases where identical functions are 
provided by elements (rovers, habitats, etc.) that are connected together on the lunar surface. We 
credit functional diversity in those cases, and in doing so compute more realistic estimates of 
operational mode availabilities. 
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1. INTRODUCTION 

NASA’s Constellation program is designed to return humans to the surface of the moon. Efforts have 
been underway at NASA centers since 2005 to plan out the details of crewed and un-crewed 
operations on the lunar surface, and to design surface elements — lunar rovers, habitats, etc. — in 
support of Constellation program goals. Although Constellation is not currently funded in NASA’s 
FY201 1 budget, efforts continue to bring the program through to the preliminary design review (PDR) 
phase of analysis and planning, at which point Constellation documents and other products will be 
archived for posterity. 

Our team at NASA Ames has developed reliability models of Constellation lunar surface elements to 
help designers identify weaknesses in element architectures. We also model the ensemble of elements 
that operate together during a lunar campaign, with the goal of helping managers and mission planners 
determine which suite of elements provides the best safety, availability, and capability at the overall 
campaign level. Funar campaigns were simulated dynamically at the architecture level using the 
GoldSim™ Monte Carlo-based risk analysis software. 

In this paper, we introduce an approach that we call ‘functional modeling’, which we have developed 
to estimate the capabilities of a lunar base, the availability of its constituent elements, and the 
availability of various modes of surface operations to the crew. 


2. FUNCTIONAL MODELING OVERVIEW 

Any human lunar campaign comprises a set of elements that are delivered to the lunar surface to 
support crewed surface operations. Figure 1 is an artist’s depiction of some of the habitat, mobility, 
and construction elements envisioned by the Lunar Surface Systems (LSS) design teams for the 
Constellation program. Each element delivered to the lunar surface provides a set of functions, such 
as life support, mobility, etc. These elements are used in various combinations by the astronauts to 
achieve their mission objectives. In some cases, surface elements may perform unique functions. In 
other cases, several elements in use together on the lunar surface may provide some redundancy in the 
functions they provide. For example, a rover and a habitat module that are connected together may 
each contribute life support functionality. In those cases, elements provide redundancy to each other 
for those specific functions. When this situation exists, we say that ‘diverse backup’ exists for that 
particular function or set of functions. 




Figure 1: Artist’s conception showing a number of surface elements in place on the lunar surface 


A surface element does not necessarily need to be fully functional in order to be available to 
accomplish a particular task. As the systems and subsystems of the surface elements fail and are 
repaired, full element functionality varies, but functional availability may not change at all, depending 
upon the redundancy (both internal to an element, and due to diverse backup) that exists in the 
elements and in the way the elements are being used as an ensemble. This fact drove us to develop a 
model that could track availability at the functional level, as well as at the element level. 

The functional modeling approach tracks the functions provided by each surface element at any given 
time during its stay on the lunar surface, in addition to tracking the state of each element’s constituent 
systems and/or subsystems. As the dynamic simulation proceeds, we track the availability of 
functions required to meet various operational demands — demands that may be in flux during a lunar 
surface campaign. By tracking functions, we are able to track the availability of different crewed or 
un-crewed operational modes, and to perform studies that help managers and mission planners to see 
the impact of varying the commit criteria for those modes, subject to assumed equipment reliability 
and repairability levels. 

Functional tracking also allows us to credit diverse backup in assessments of campaign-level 
functionality for crew activities, such as certain roving operations that require several surface elements 
to be available concurrently. By tracking the availability of diverse backup during different equipment 
use configurations and activities on the surface, we provide a more realistic picture of the severity, if 
not survivability, of various failure scenarios. Further, we are able to run sensitivity studies on the 
level of availability provided by a set of surface elements, under different assumptions of the amount 
of diverse backup deemed acceptable for a given function (such as life support), or under varying 
repairability assumptions. We are able to credit partial availability of the various elements, thus 
obtaining a truer picture of that element’s utility to astronaut crews at any point in the campaign. 



3. LUNAR SURFACE ELEMENT MODELS 


For each surface element in the lunar campaign, we perform a thorough assessment to determine its 
comprising systems and subsystems. Through detailed discussions with the element design teams, 
assessment of the system schematics, and careful review of the master equipment lists (MELs), the 
individual failure rates for major components in each subsystem are assessed and the string structure 
of the systems/subsy stems comprising the element is determined. We use a combination of historical 
data (from the Space Shuttle and International Space Station), expert opinion, and comparative 
analogy with the mining and oil/gas industries to estimate component failure rates within each string. 
Here, a string is defined as a single closed loop in any subsystem design that performs a specific 
function, and for which any component failure within the string causes the entire string to fail. The 
failure rate for each redundant string, denoted A, n , is computed by summing the failure rates of the 
string’s constituent components. We assume that components fail due to random events only, and thus 
the probability density function of component failures is an exponential distribution. 

Figure 2 illustrates this step in the modeling process, using the Environmental Control and Life 
Support System (ECLSS) of the Pressurized Core Module (PCM) element as an example. The PCM is 
a pressurized human habitation element proposed by the Constellation LSS architecture team. In the 
figure, five ECLSS subsystems are identified: fire detection/suppression, air revitalization, water 
recovery, waste management, and a pressure control subsystem (PCS). The string structure within the 
subsystems is shown (purple boxes), characterized by mean failure rates A*. The specific string 
structure shown in the figure is for illustrative purposes only, and does not necessarily represent the 
true ECLSS structure. 



Figure 2: A symbolic representation of the subsystem-level models used in the Lunar Surface 
Systems (LSS) risk analysis. The Environmental Control and Life Support System (ECLSS) is 

shown in this examples 
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To each subsystem, we map a set of external dependencies, such as power, fuel, life support, etc., that 
are required for the subsystem to be operational. Systems contained within a surface element work 
together to provide the functions that the element is designed to deliver, such as mobility, 
communications, life support, or others. These three basic building blocks— systems/subsystems, 






external dependencies, and functions provided— combine to represent an element in the functional 
model. This is shown symbolically in Figure 3 for the PCM element. Note that the ECLSS system of 
Figure 2 is represented as one of the five PCM systems in Figure 3. 

In our model, an element’s systems act like engines; consuming external dependencies like fuel, and in 
turn providing functions to the lunar campaign. Multiple subsystems or systems may be required to 
support a given function. For instance, in the PCM example shown in Figure 3, the ECLSS, Thermal, 
and Environmental Protection systems together contribute to the function Environmental Protection, 
which the element provides to the lunar base habitat. Power is required by these three systems as an 
external dependency. Although mapping of external dependencies and functions to the element is 
done at the subsystem level in our model, Figure 3 shows this mapping at the system level for clarity. 

Figure 3: The Pressurized Core Module (PCM) element model, showing the element proper 
(blue) with its systems (light green) and subsystems (light yellow), its external dependencies 
(red), and a generic set of functions that elements may or may not provide (dark yellow). The 
dependencies and functions provided map according to the black arrows shown (power maps to 

all systems). 



4. LUNAR BASE MODEL AND RESULTS 

We use the GoldSim™ Monte Carlo-based risk analysis software to model Constellation lunar surface 
campaigns. In our model, we implement the symbolic logic of Figure 3 for each surface element 
populating the lunar base, which may comprise as many as 25 independent elements. Constellation 
lunar campaign scenarios consist of approximately 37 flights to the moon over a 10- to 12-year period, 
totalling more than 2000 planned days of human lunar habitation. During the lunar campaign 
simulation, we toggle elements ‘on’ in the GoldSim™ model according to a cargo manifest that 
defines the planned element delivery dates and crew arrival/departure dates. We toggle the elements 
‘off (or to a reduced exposure mode) in the model when the astronaut crew leaves the surface. 





As the model runs, the various strings of each element subsystem fail, and are repaired with a 
probability determined by a general repairability assumption for the lunar campaign. We explicitly 
track the following metrics. 

1 . State of Element Repair: At each time step in the Monte Carlo simulation, we record the state 
of each lunar surface element, creating a record of the systems and subsystems that are 
operating or failed. This information is used in the functional availability tracking we 
describe below. As a prerequisite for any rover/sortie activity, we require the participating 
surface elements to be fully operational (i.e., all strings must be operational) in our model. 

For power-producing elements, we track the specific power output as a function of time. 

2. Outcome of Repair Attempts: We record the total number of successful repairs made to each 
subsystem during the course of a complete lunar campaign. If a repair attempt fails in our 
simulation, a second attempt is not made. We assume that a failed repair requires launching a 
replacement string on a future re-supply flight from earth. As the system design matures and 
we obtain estimates of the mass contained in each element’s subsystem strings, we can use our 
simulated failed string counts to compute the average failed mass as a function of time — i.e., 
the total extra mass that must be delivered to the moon to support the upkeep of the lunar base. 
Since this ‘repair mass’ will displace other payload mass carried to the lunar surface, it is an 
important metric to report, potentially helping managers to trade off system reliability 
requirements with system repairability. 

3. Functional Availability: A temporal history of the functional availability of all elements is 
recorded. With this information, we track the overall availability of different operational 
modes as a function of mission elapsed time (MET), crediting diverse backup depending on 
how the surface elements are connected together and used by the crew. By adjusting the 
commit criteria (i.e., the state of repair/functionality that must exist before initiating a 
particular activity on the surface) and functionality requirements for different operational 
modes, we can perform sensitivity studies that help managers and mission planners to see the 
impact of different operational rules, subject to assumed equipment reliability and repairability 
levels. 

The results of some of our preliminary studies are presented in Figures 4-6. In Figure 4, we show the 
expected power output (as a function of MET) of the fission surface power system (FSPS), a nuclear 
reactor that is under study by Constellation mission architects. In the simulation, the reactor is 
designed to produce 48 kW of power. A portion of the reactor is not serviceable, leading to a steady 
expected decline in output power over the reactor’s life, for the case where the serviceable part of the 
reactor is always repaired successfully. The figure shows the failure counts instead of a repairability 
percentage. This is another useful metric, as it may help to set expectations for the level of 
extravehicular activity (EVA) support required of the astronauts. On average, the serviceable portion 
of the reactor — comprising its electrical power distribution system — required 32 repair operations 
during a 4000-day simulation period. 

We reduce the number of allowed repairs to investigate the effect that repair limitations (due to limited 
space for spare parts on cargo landers, limited EVA schedules, etc.) have on the available power. 
Current design guidelines for the reactor require the output power to exceed 20 kW after about 3000 
days of continuous operation. On average, the current model suggests that mission planners allocate 
resources (time, equipment) to support a minimum of 25 repairs to the reactor in order to meet this 
performance guideline. 



Figure 4: Power output vs. mission elapsed time of the fission surface power system (FSPS), a 
space-qualified nuclear reactor studied for possible inclusion in the Constellation architecture. 
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Figure 5 shows the availability of pressurized surface habitation as a function of MET. Individual 
curves correspond to different levels of repairability, as indicated. The effect of diverse functional 
backup is included in the figure; in this example, diversity is provided for habitation by three 
pressurized habitat modules (one of which is the PCM), four rovers (which connect to the PCM and 
provide redundant ECLSS), three solar power generators, and a nuclear power generator. The delivery 
of these habitation, roving, and power elements occurs between day 1025 and day 2120 MET in the 
model, causing an initial increase in the operational availability in the figure. In Figures 5 and 6, gaps 
in the curves represent periods in the mission plan when crews are not present on the surface. 

The power of the functional modeling approach is illustrated in Figure 6. Here, we compare the 
surface habitation availability computed using our functional model with an availability estimate 
computed assuming that no diverse backup is available. The two results are presented for the case 
where 80% of all attempted repairs (to all elements) are successful. Because it accounts for diverse 
backup, the functional model predicts much greater habitat availability, and thus provides a more 
realistic assessment of the expected performance of the habitat as an ensemble. 
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Figure 5: Availability of pressurized surface habitation as a function of equipment repairability. 
The results reflect the availability of diverse functional backup from lunar excursion rovers 
(LERs), multiple pressurized modules, and multiple power sources. 



Figure 6: Comparison of the estimated operational availability of a pressurized habitat 
computed with and without a functional modeling approach. The functional model gives full 
credit for diverse backup. Both models assume 80% repairability. 
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5. CONCLUSION 


The functional modeling approach yields more realistic estimates of the availability of the various 
operational modes provided to astronauts by the ensemble of surface elements included in a lunar base 
architecture. By tracking functional availability the effects of diverse backup, which often exists when 
two or more independent elements are connected together, is properly accounted for. 
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